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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards" , which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://www.etsi.org/ipr) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE 1: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 60 
countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Eureka Project 147 was established in 1987, with funding from the European Commission, to develop a system for 
the broadcasting of audio and data to fixed, portable or mobile receivers. Their work resulted in the publication of 
European Standard, EN 300 401 [1], for DAJJ (see note 2) which now has worldwide acceptance. The members of the 
Eureka Project 147 are drawn from broadcasting organizations and telecommunication providers together with 
companies from the professional and consumer electronics industry. 

NOTE 2: DAJ3 is a registered trademark owned by one of the Eureka Project 147 partners. 



Introduction 



The user application Slide Show provides the user with a sequence of slides which carry information in form of images. 
The shdes will be presented on an appropriate display. 

The main use for this user application will be in context with a programme service component. Examples are: 

• news programme items complemented by photos from the reported events; 

• programme items with popular songs accompanied by the photos of the favourite groups or the covers of the CD 
the songs are taken from. 

The user application may also be provided as a data service component and may show e.g. the panorama, to be seen 
from different mountains, so to inform hikers and skiers about the different local conditions and to support them in 
deciding where to pursuit their sporting activity best. 
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The slides may carry not only photos or graphics, but also text. However, the Slide Show user application is optimized 
for conveying photos and graphics, but not for text. So text has to be rendered and sent as an PNG or JPEG image. If the 
application provider wishes to convey text adapted and optimized to the DAB transmission chain and to the resources at 
the receiving terminal, he is advised to make use of either the user application "Dynamic Label" or the user application 
"Broadcast Web Site" [4]. 

Once activated the Slide Show is a service provider driven user application, i.e. it does not require any interaction from 
the user of the corresponding service component, but each slide appears automatically on the display and will be 
replaced under the control of the service provider according to the needs of his service. 

The user application Slide Show can be realized in the following ways: 

• in the PAD of a programme service, with no separate identifier nor a separate label; in that case it is no 
(secondary) component of the programme service; 

• as a secondary data service component of a programme service, i.e. belonging to a 16 bit "mother" programme 
service, with its own identifier (SCId) and possibly its own service component label; in that case it is transported 
in packet mode (TMId =11) with DSCTy = MOT and available in a particular subchannel; 

• as the primary service component of a data service (i.e. with a 32 bit Service Id); 

• as a secondary data service component of a "mother" data service with its own identifier (SCId) and possibly its 
own service component label; in that case it is transported in packet mode (TMId =11) with DSCTy = MOT and 
available in a particular subchannel. 
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Scope 



The present document describes the protocol required to create the DAB user appHcation "MOT Slide Show". 

The "MOT Slide Show" user application applies the DAB-MOT protocol [3] and allows a service provider to deliver a 
sequence of slides which carry information in form of images. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 



[1] 

[2] 
[3] 

[4] 
[5] 



ETSI EN 300 401: "Radio Broadcasting Systems; Digital Audio Broadcasting (DAB) to mobile, 
portable and fixed receivers". 

ETSI TS 101 756: "Digital Audio Broadcasting (DAB); Registered Tables". 

ETSI EN 301 234: "Digital Audio Broadcasting (DAB); Multimedia Object Transfer (MOT) 
protocol". 

ETSI TS 101 498: "Digital Audio Broadcasting (DAB); Broadcast website". 

ISO/IEC IS 15948: "Information technology - Computer graphics and image processing - Portable 
Network Graphics (PNG): Functional specification". 



3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



CD 

DAB 

FIC 

FIDC 

FIG 

JPEG 

MOT 

MSC 

PAD 

PNG 

UA 

UTC 

WIRC 



Compact Disk 

Digital Audio Broadcasting 

Fast Information Channel 

Fast Information Data Channel 

Fast Information Group 

Joint Pictures Expert Group 

Multimedia Object Transfer 

Main Service Channel 

Programme Associated Data 

Portable Network Graphics 

User Application 

Universal Time Coordinated 

WorldDAB Information and Registration Centre - a WorldDAB office for co-ordinating the 

technical developments of DAB 
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4 Maintaining tables of registered values 

The present document contains identifier fields that require values to be registered. Registered value lists associated 
with data broadcasting specifications for DAB are maintained by the WorldDAB Information and Registration Centre 
(WIRC). Since the lists and tables contained within the present document might be outdated, please refer for the most 
actual versions to TS 101 756 [2]. The present document describes also the procedures for registering values in an 
existing table as well as registering new tables. 



5 Operation of the MOT Slide Show user application 

The Slide Show user application simply conveys one slide at a time from the user application provider to the slide show 
terminal. After complete and error-free reception it is presented on the display as triggered by the user application 
provider and replaces the previous slide. 

The exact details on the timing issues are given in clause 5.4. 



5.1 Transport 



The Slide Show user application applies the MOT protocol: Each slide, together with its parameters, is taken as one 
MOT object: it is segmented and its segments are transferred according to the rules of the MOT protocol. MOT headers 
and bodies are used. 

A Slide Show may be transferred either in the PAD part of a MSC stream audio sub-channel or in a MSC packet mode 
data sub-channel. 

Wireless broadcast channels like DAB may be disturbed and so bit errors may corrupt the objects. Therefore the objects 
should be repeated sufficiently, applying one of the repetition methods offered by the MOT protocol and/or the DAB 
system itself. 

The slides will experience different delays (according to different reception conditions in different places), until the 
complete object is available in an error-free state to all the terminals within the intended coverage area. If the user 
application provider wants to ensure a precise start of the slide presentation, he has to start the transmission sufficiently 
in advance and to set the TriggerTime parameter to a value not equivalent to NOW. 

5.2 Storage and memory management 

The user application requires the receiving terminal to control basically four buffers, one buffer for re-assembly of the 
currently received segments of the incoming slide, one buffer for holding the slide for rendering (JPEG decoding for 
example), the third one for storing the image in a presentable format (i.e. bitmap) and the fourth buffer for holding the 
slide currently being presented on the display. 

Figure 5.1 describes the way from the re-assembly to the presentation: 




NOTE: When the TriggerTime is reached a slide would be copied from the rendering buffer to the screen buffer. 
Figure 5.1 : Buffer management model for a MOT Slide Show decoder 
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5.3 Presentation 



The Slide Show user appHcation works with one display only: it can present one slide at a time. 

Before an object can be presented as a slide, its content has to be handled by the source decoder, e.g. in case of a JPEG 
picture it has to be processed by the JPEG decoder. The content decoding requires processing time which may delay the 
presentation, in addition to the transmission delay. 

The presentation time of the new slide can be controlled by the user application provider, as will be explained below. 
However, there is no explicit way of removing a slide from the display. It can only be replaced by a new one. It is the 
task of the user application provider to ensure that the slides presented are always up-to-date and that especially at the 
junction between different programme items no obsolete information is left on the display. This, for example, can 
simply be realized by transmitting and displaying the station logo or an "empty" slide. 

If a slide is completely rendered and a new slide is received before the old slide is triggered, then the old slide shall be 
discarded and the new slide shall be processed. 

The provider can control the presentation start of a slide by using one of three options: 



• 



• 



TriggerTime: Now 

The slide is presented immediately after complete, error-free reception and content decoding. The presentation 
will vary at different terminals, because they will work under different reception conditions and with different 
processing speed. As a result, the start of the presentation may differ by several seconds or even tens of seconds. 

TriggerTime: UTC 

The desired precise TriggerTime is given in Universal Time Co-ordinated (UTC) and is sent (as part of the 
Header) together with the slide (Body) within the same object. This mechanism mandatorily requires the 
provision of FIG 0/10 in the FIC, which contains the exact UTC (not the Local Time!) as a reference value. 
Under normal operation conditions, all terminals will have the slide available before its signalled presentation 
start (TriggerTime). The presentation (copying the slide to the screen buffer) is triggered as scheduled and 
therefore independent from the variations of the reception conditions and the processing speed. This option, 
however, requires that the user application provider fixes the presentation time in advance, i.e. before the 
transmission of the object is started. This may be difficult, when the presentation has to be synchronized 
precisely to a programme service component, i.e. it has to be synchronized to the first beats of a music title, 
because in some operational environments this information is not available sufficiently in advance or because in 
live transmission the start of the new item is decided immediately before start by an operator, without look ahead 
time. This difficulty can be avoided, if the third option is applied. 

Header update 

The slide is transmitted as an object without any information about the TriggerTime, but sufficiently in advance, 
so that all terminals will have received and rendered the object. As soon as the user application provider has 
decided on the TriggerTime, a Header update object containing the TriggerTime (as UTC or as value "now") is 
transmitted. This Header update object will experience no significant transmission delay, because it is of relative 
small size. 

The user application may be terminated by updating the FIG 0/13 signalling. DAB data terminals will usually react on 
the termination of an application by making another application automatically available for the user i.e. another 
secondary data service component or another application in PAD. 

5.4 Timing issues 

The model of a MOT Slide Show decoder shown in figure 5.1 implies: 

While a slide is being rendered, its holding buffer must not be overwritten with the next slide (or Header update). If the 
processing power of the MOT Slide Show decoder is too low to process every slide, it shall not copy objects into the 
holding buffer before the rendering of the slide already contained in the holding buffer is completed. This means that 
the slow MOT Slide Show decoder will discard some slides, but display as many as possible. 

The user application provider should try to give the MOT Slide Show decoder as much time as possible to render a slide 
before the next object is broadcast. 
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The lifetime of a slide inside the MOT Slide Show decoder is as follows: 

TT(n) RT{n) WT (n) PT (n) 

\ \ \ \ \ ^ 

TO(n) Tl{n) T2 (n) T3 (n) T4 (n) 

TT(n): Transmission Time period for object n. It starts with the first segment received from the object and ends when 
the object is completely re-assembled and copied into the holding buffer. 

RT(n): Rendering Time period for object n. It starts when a slide is copied into the holding buffer and ends when it is 
rendered into the rendering buffer. 

WT(n): Waiting Time period for object n. It starts when the slide is rendered and ends when it is copied to the screen 
buffer. The time when it is copied is determined by the TriggerTime parameter (either delivered together with the slide 
within the same object or transmitted as a separate object after the slide object). 

PT(n): Presentation Time period for object n. It starts when the slide is copied to the screen buffer and ends when the 
next slide replaces this slide or the Slide Show is terminated (signalled in the FIC). 

The provider knows the time instant TO(n) (start of transmission of object n), Tl(n) (end of transmission of object n), 
T3(n) in the case that a TriggerTime not equivalent to NOW is signalled (start of presentation of object n) and T4(n) 
(end of presentation of object n, either identical with T3(n + 1) or with the dropped signalling of the user application in 
the FIC). 

The user application provider should assure that Tl(n) is later than T2(n - 1), which means that the previous slide is 
already rendered before the transmission of object n is completed. Unfortunately the provider does not know the T2 
instances (end of the rendering process). In the case of TriggerTimes not equivalent to NOW (corresponding objects 
need to be transmitted sufficiently in advance, i.e. with a distance in time longer than the longest supported rendering 
time before the scheduled appearance of the slide on the display) the user application provider knows when the slide is 
displayed (T3(n - 1)) and therefore the transmission of a slide could be finished after T3 (n - 1), because then the 
rendering buffer will be available. 

If TriggerTime NOW is signalled, the provider should estimate the rendering time and use the estimated point of time 
T3(n - 1) to determine when the holding buffer is available. 

NOTE: JPEG rendering times for current data terminal implementations (1997) are in the range of 2 s to 15 s, 
depending on the image complexity and computing power of the decoder hardware. 

The transmission of an object can be started before the holding buffer is available, but it should not be finished before 
this buffer is available. So it is possible, for example, to broadcast all but the last segment of the object and transmit the 
last segment (and possibly repeat it) after T3(n - 1). 

The user application provider also has to assure that Tl(n) occurs after T3(n - 1), which means that the rendering of a 
slide is not started before the previous slide is copied into the screen buffer. That is, because overwriting the rendering 
buffer starts when new input enters the holding buffer. 

Conclusion: 

The transmission of an object (slide or Header update) should not be finished before the previous slide has been 
displayed. In other words: the end of the previous slide's transmission plus its estimated rendering time plus possibly a 
waiting time (resulting from a TriggerTime not equivalent to NOW) should have been expired before. 
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Interface to the Transport layer MOT 



Slide Shows are implemented in the DAB system by transferring the slides including all necessary control information, 
as objects according to the Multimedia Object Transfer protocol MOT used with the two Transport Mechanisms "MSC 
stream audio" (PAD part) and "MSC packet mode data" (Transport Mechanisms "MSC stream data" or "FIDC" are not 
enabled). 

MOT headers and bodies are used (MOT Directory shall not to be used). 

6.1 MOT ContentTypes and ContentSubTypes 

According to the MOT protocol, each object has to be characterized by its ContentType and ContentSubType. The user 
application requires this information in order to address the corresponding content decoders correctly. The following 
types are permitted for the use in the Slide Show user application: 

6.1 .1 ContentType "Image" 

6.1 .1 .1 ContentSubType "JFIF" (JPEG) 

The image/ jpeg content type shall be deemed to indicate content conforming to the following restrictions: 

• only baseline coding is used; 

• progressive and/or multiscan coding is not used; 

• arithmetic entropy coding is not used; 

• the JPEG file must not contain more than 4 components (colour channels); each component is restricted to a 
resolution of 8 bit/component. 

6.1 .1 .2 ContentSubType "PNG" 

The image /png content type shall be deemed to indicate content conforming to version 1.1 of the PNG specification 
(ISO/IEC IS 15948 [5]). No extension "chunks" outside this PNG specification need to be supported. 

6.1.2 ContentType "MOT transport" 
6.1 .2.1 ContentSubType "Header update" 

In addition to the objects carrying the slides themselves, special objects with ContentType "MOT transport" and 
ContentSubType "Header update" can be used to transmit the TriggerTime for the presentation of the slide that is 
broadcast most recently. It is sent only, if that slide object has been broadcast or is being broadcast without a 
TriggerTime parameter. 

The "Header update" object carries the following parameter: 

• ContentName: This parameter is used to link the Header update to the slide object, the TriggerTime of which is 
to be updated. 

NOTE: The ContentName must refer to the slide that was sent directly before the "Header update". It is not 

possible to send multiple slides in advance and trigger any one of those. If the "Header update" does not 
refer to the slide in the holding/rendering buffer then both the "Header update" and the slide shall be 
removed from their respective buffer. 

• TriggerTime: This parameter carries the update information, i.e. the TriggerTime parameter of the slide object. 
The TriggerTime parameter may carry either the value NOW or a value coded as UTC. There is only one value 
for the TriggerTime parameter allowed, i.e. the parameter may occur in the Header update object only once. 

No further parameters are needed to be carried in the Header update object. 
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6.2 MOT Parameters for the slide objects 

Only the MOT parameter ContentName is mandatory and must be used for each shde object that will be handled by the 
MOT decoder and the memory management of the Slide Show terminal. 

6.2.1 ContentName 

According to the MOT protocol the ContentName is needed for identifying and handling the object in the memory 
management. Therefore its use is mandatory within the Slide Show user application. While it is not mandatory for the 
ContentName to be changed with each slide, it is strongly recommended that this is done. This will prevent problems 
with object management throughout the processing chain (see model in clauses 2.2 and 2.3) and particularly with the 
Header update mechanism. Service providers should be aware that failure to change the ContentName may result in the 
receiver presenting the user application incorrectly. 

If a service provider chooses to keep the ContentName constant and to use the VersionNumber mechanism to indicate a 
change of the slide, the fact that the Transportid must necessarily change means that all receivers, including new ones, 
should still correctly detect the change of the slide. 

6.2.2 TriggerTime 

The service provider controls the presentation of the slide by setting this MOT parameter. If a slide object is broadcast 
without any TriggerTime parameter, it can only be presented by the terminal, if this slide object is directly followed by 
a "Header update" object with the TriggerTime for that slide. 

The parameter TriggerTime is permitted only once, i.e. if this object is to be presented later on once again, it has to be 
broadcast once again completely. It is not sufficient to send only the new TriggerTime (by a Header update or by 
sending a new header for that slide object), because the slide show terminal is not expected to store the object after this 
object has been replaced by the presentation of a new slide. 

The TriggerTime parameter can take the value NOW or a value coded in UTC. If the TriggerTime is coded in UTC, the 
Slide Show terminal has to assure that the presentation of the slide can start at the given time instant. 

6.2.3 Other MOT parameters 

Other parameters possibly signalled in the MOT Header will be ignored by the Slide Show terminals. 



7 Requirements and limitations 

The following requirements and limitations have to be taken into account: 



• 



The display resolution for presenting the user application Side Show should be 320x240 pixels at a colour/grey 
scale depth of 8 bits per pixel (1/4 VGA). 



• The slide must be completely displayed on the 1/4 VGA screen without the need for horizontal and/or vertical 
scrolling. 

• The maximum file size of a slide (JPEG or PNG) shall not exceed 50 kbit/s. 



8 Restrictions that apply to pilot project receivers 

The first implementation of Slide Show terminals rely on the parameter TriggerTime. By its presence it is indicated to 
the terminals, that a Slide Show user application is available and that this object is at least part of that Slide Show. 

Therefore its use is mandatory, if those first implementations of Slide Show decoders are expected to present it. A 
further restriction is that they understand only TriggerTimes NOW. In order to recognize a new slide a changed 
ContentName or a changed VersionNumber (or both) is required by these first implementations. 
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